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Description 



METHODS AND SYSTEMS FOR TICKET VOUCHER FLOW CONTROL IN 



The present invention relates to methods and systems for message 
flow control in response to signaling link failure. More particularly, the present 
invention relates to methods and systems for ticket voucher flow control in 
1 0 response to signaling link failure. 



In a common channel signaling network, such as an SS7 network, call 
signaling messages are used to set up and tear down calls between end 
15 users and to communicate with databases. These call signaling messages 



messages to the appropriate destination. The signaling links can be SS7 
signaling links, IP signaling links, or other signaling links suitable for carrying 
call signaling messages. The node that conventionally handles such signaling 
20 links is referred to as a signal transfer point or a signaling gateway. 

One problem with conventional signal transfer points or signaling 
gateways occurs when one of the signaling links fails. When a signaling link 
fails, messages directed to that link are buffered. The signal transfer point or 



RESPONSE TO SIGNALING LINK FAILURE 



5 



Technical Field 



Background Art 



are sent over signaling links to a signaling node that routes the call signaling 
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signaling gateway determines an alternate route to the destination and sends 
the buffered messages over an alternate outgoing signaling link (if available) 
that has not failed. Because SS7 signaling links are typically underutilized, 
i.e., only about 40% of total capacity is typically used, the message transfer 
5 rate of the outgoing signaling links can be increased relative to the message 
transfer rate of the incoming signaling links until all of the messages that were 
buffered for the failed signaling link have been transmitted. Once the 
signaling gateway transmits all of the buffered messages, the capacity of the 
outgoing signaling link can be decreased back to its normal level. 

10 The process described above for responding to a signaling link failure 

works well only when the incoming and outgoing signaling links are low speed 
signaling links, i.e., capable of processing no more than about 300 messages 
per second. If the incoming signaling link is a high speed signaling link, i.e., 
capable of processing 2000 or more messages per second, the buffer used to 

15 store messages when the outgoing signaling link fails can quickly be overrun. 
In addition, even if the buffer is not overrun, it may take a long period of time 
for the outbound signaling link to deplete the messages stored in the buffer 
when another signaling link fails. Thus, there exists a need for novel methods 
and systems for performing flow control between incoming and outgoing 

20 signaling links in a signaling point when one or more of the signaling links 
fails. 

Disclosure of the Invention 
According to one aspect, the present invention includes methods and 
25 systems for flow control through a signaling node when a signaling link fails 




using ticket voucher messages. As used herein, ticket voucher messages are 

* 

messages transmitted between inbound and outbound communication 
modules to throttle the flow of call signaling messages when a signaling link 
fails. Ticket voucher messages have conventionally been used between link 
5 interface modules and signaling connection control part (SCCP) cards to 
indicate whether the SCCP cards have the capacity to perform operations, 
such as global title translation, on incoming messages. The present invention 
includes novel methods and systems for using ticket voucher messages to 
throttle traffic between communication modules in a signaling node when one 

10 or more signaling links fail. 

The present invention will be explained below in terms of modules or 
processes for performing ticket voucher flow control. It is understood that 
these modules or processes may be implemented in hardware, software, or a 
combination of hardware and software. Accordingly, some embodiments of 

15 the present invention may be implemented as computer program products 
comprising computer executable instructions embodied in a computer 
readable medium. 

Accordingly, it is an object of the present invention to provide novel 
methods and systems for performing flow control between communication 
20 modules in a signaling node when one or more signaling links fail. 

Some of the objects of the invention having been stated hereinabove, 
other objects will be evident as the description proceeds, when taken in 
connection with the accompanying drawings as best described hereinbelow. 




Brief Description of the Drawings 
A description of the present invention will now proceed with reference 
to the accompanying drawings of which: 

Figure 1 is a block diagram of an exemplary operating environment for 
5 embodiments of the present invention; 

Figure 2 is a block diagram of a conventional signaling gateway to 
which ticket voucher flow control methods of the present invention may be 
applied; 

Figure 3 is a block diagram illustrating the internal architecture of a 
10 signaling gateway including one or more ticket voucher flow control processes 
according to an embodiment of the present invention; 

Figure 4 is a block diagram of a link interface module including a ticket 
voucher flow control process according to an embodiment of the present 
invention; 

15 Figure 5 is a flow chart illustrating exemplary steps that may be 

performed by an MTP routing process modified to operate with a ticket 
voucher flow control process according to an embodiment of the present 
invention; 

Figure 6 is a flow chart illustrating exemplary steps that may be 
20 performed by a ticket voucher flow control process in issuing a ticket voucher 
request according to an embodiment of the present invention; 

Figure 7 is a block diagram illustrating an exemplary packet structure 
for a ticket voucher flow control message according to an embodiment of the 
present invention; and 




Figure 8 is a flow chart illustrating exemplary steps that may be 
performed by a ticket voucher flow control process in processing a ticket 
voucher request according to an embodiment of the present invention. 

5 Detailed Description of the Invention 

Figure 1 illustrates an exemplary operating environment for 
embodiments of the present invention. In Figure 1, a signaling gateway 100 
includes ticket voucher flow control processes 102 associated with signaling 
links 104 to regulate the flow of messages when one of the signaling links 104 

10 fails. Signaling links 104 can be any type of signaling link used to 
communicate call signaling messages. For example, the signaling links can 
be SS7 signaling links, TCP/IP signaling links, or any other type of signaling 
links used to communicate call signaling messages. Signaling gateway 100 is 
preferably capable of receiving call signaling messages and routing the call 

15 signaling messages to the appropriate destination. In the illustrated 
embodiment, signaling gateway 100 is configured to communicate with a 
service switching point 106, a signal transfer point 108, a service control point 
110, and a media gateway controller 112. However, the present invention is 
not limited to communicating with only these signaling nodes. The signaling 

20 nodes illustrated in Figure 1 are shown for illustrative purposes only. 

With the exception of ticket voucher flow control process 102, the 
internal architecture of signaling gateway 100 may be similar to that of the 
EAGLE® signal transfer point or the IP 7 SECURE GATEWAY™ available from 
Tekelec, Inc., of Calabasas, California (hereinafter, "Tekelec"). A detailed 

25 description of the EAGLE® STP may be found in EAGLE® Feature Guide 



PN/91 0-1 225-01, revision B, January 1998, published by .Tekelec, the 
disclosure of which is incorporated herein by reference in its entirety. 
Similarly, a detailed description of the IP7 SECURE GATEWAY™ may be 
found in Tekelec publication PN/909-0767-01 , revision B, August 1991, 
5 entitled "Feature Notice: IP7 SECURE GATEWAY™ Release 1," the 
disclosure of which is incorporated herein by reference in its entirety. The 
specific functions of the IP7 SECURE GATEWAY™ for transmitting and 
receiving TCAP messages over an Internet protocol network are described in 
PCT Publication No. WO 00/35155, the disclosure of which is incorporated 

10 herein by reference in its entirety. Similarly, the functional components of the 
IP7 SECURE GATEWAY™ for transmitting ISUP messages over an Internet 
protocol network are described in PCT Publication No. WO 00/35156, the 
disclosure of which is incorporated herein by reference in its entirety. 

Figure 2 illustrates the internal subsystems of an EAGLE® STP or an 

15 IP7 SECURE GATEWAY™ to which the methods for performing ticket 
voucher flow control according to the present invention may be applied. In the 
illustrated embodiment, STP or signaling gateway 200 includes the following 
subsystems: a maintenance and administration subsystem (MAS) 202, a 
communication subsystem 204, and an application subsystem 206. The 

20 maintenance and administration subsystem 202 provides maintenance, 
communications, initial program loading, peripheral services, provisioning 
capability, alarm processing, and system disks. Communication subsystem 
204 includes an interprocessor message transport (IMT) bus that is the main 
communication bus among all of the subsystems in signaling gateway 200. In 




a preferred embodiment, the interprocessor message transport bus includes 
two 125 Mbps counter-rotating serial buses. 

Application subsystem 206 includes cards that are capable of 
communicating with other cards through the IMT bus. Numerous types of 
5 application cards can be incorporated in signaling gateway 200. Examples of 
such cards includes a link interface module (LIM) 208 that provides SS7 and 
X.25 links, a data communications module (DCM) 210 that provides SS7-to- 
TCP/IP and TCP/IP-to-SS7 translation, and an application service module 
(ASM) 212 that provides global title translation, gateway screening, and other 

10 services. A translation service module (TSM) 214 may also be provided to 
support local number portability service. While multiple application modules 
or cards may be simultaneously configured and operatively connected to the 
IMT bus, it will be appreciated that each card is assigned a unique IMT bus 
address so as to generally facilitate the internal communication of messages 

15 between provisioned cards that are attached to the IMT bus. Once again, a 
detailed description of the EAGLE® STP other than DCM 210 is provided in 
the above-cited EAGLE® Feature Guide and need not be described in detail 
herein. DCM 210 is described in detail in the above-referenced International 
Patent Publications. 

20 With regard to communication type modules, DCM card 210 can be 

used to communicate IP-encapsulated SS7 messages over an IP network, as 
described in the above-referenced Feature Notice IP7 SECURE GATEWAY^ 1 
release 1.0 publication. With regard to the TSM module and triggered LNP 
services mentioned above, a detailed description of the triggered LNP 

25 functionality of an STP or a signaling gateway can be found in Feature Guide: 



LNPLSMS PN/91 0-1 58-01, revision A, January 1998, published by Tekelec, 
the disclosure of which is incorporated herein by reference in its entirety. 
Furthermore, systems and methods for providing triggerless LNP functionality 
within a network routing node are described in commonly-assigned, 
5 copending U.S. Patent Application No. 09/503,541, filed February 14, 2000, 
the disclosure of which is incorporated herein by reference in its entirety. 

Figure 3 is a block diagram of an exemplary internal structure of 
signaling gateway 100 according to an embodiment of the present invention. 
For convenience, only the interface modules that communicate with external 

10 call signaling links are illustrated. It is understood that signaling gateway 100 
may include other modules, such as LIMs, DCMs, TSMs, ASMs, etc., as 
discussed above with respect to Figure 2. In the illustrated embodiment, 
signaling gateway 100 includes Internet protocol link interface modules (IP 
LIMs) 300, 302, 304, and 306 for communicating with external nodes over 

15 signaling links 104. Although the IP LIMs can be configured to communicate 
with any number of external signaling links, in Figure 3, each IP LIM manages 
two signaling links 104. 

Each of the Internet protocol link interface modules 300, 302, 304, 
and 306 may be a separate card or printed circuit board with its own resident 

20 microprocessor and memory devices. Alternatively, IP LIMs 300, 302, 304, 
and 306 may be separate processes executing on the same microprocessor 
using a time sharing algorithm. In the illustrated embodiment, IP LIMs 300, 
302, 304, and 306 are connected to each other by an interprocessor message 
transport bus 308. IMT bus 308 may be a dual-ring, counter-rotating bus for 

25 providing additional reliability in the event that one of the Internet protocol link 



interface modules fails. IMT bus 308 carries messages, such as call signaling 
messages, between Internet protocol link interface modules and any other 
modules included in signaling gateway 100. In addition, according to the 
present invention, IMT bus 308 carries ticket voucher request and grant 
5 messages between Internet protocol link interface modules 300, 302, 304, 
and 306. The generation and transfer of the ticket voucher grant and request 
messages will be discussed in more detail below. 

Figure 4 is a block diagram illustrating an Internet protocol link interface 
module according to an embodiment of the present invention in more detail. 

10 In Figure 4, Internet protocol link interface module 300 includes a plurality of 
processes for handling incoming and outgoing messages as well as 
processes for performing ticket voucher flow control according to 
embodiments of the present invention. For example, Internet protocol link 
interface module 300 includes an SS7/IP and IP/SS7 converter 400 for 

15 converting messages between SS7 and IP and vice versa. L2 to L3 
queue 402 stores SS7 messages between SS7 layer 2 and layer 3 processes. 
Message handling and discrimination (HMDC) process 404 determines 
whether an inbound SS7 message is directed to this signaling gateway or to 
another signaling node. This determination may be based on the MTP routing 

20 label in the SS7 message. If HMDC process 404 determines that the 
message is directed to this signaling node, HMDC process 404 routes the 
message to message handling and distribution (HMDT) process 406 to be 
routed to an internal card for further processing. An example of such a 
message that requires further processing is a message that requires global 

25 title translation. Such processing is not of importance to the present invention. 




Accordingly, in the remaining explanation, it is assumed an incoming message 
is routed to an external node. 

Once HMDC process 404 determines that a message is to be routed to 
an external signaling node, HMDC process 404 forwards the message to MTP 
5 routing process 408. MTP routing process 408 examines signaling 
information in the message and determines the internal IMT bus address of 
the communications module that manages the outbound signaling link to 
which the message is addressed. According to the present embodiment, MTP 
process 408 also communicates with ticket voucher flow control process 402 

10 to regulate message flow in the event of a link failure. 

Figure 5 illustrates exemplary steps that may be performed by MTP 
routing process in regulating message flow based on ticket voucher grants 
according to an embodiment of the present invention. Referring to Figure 5, in 
step ST1, MTP routing process 408 selects an outgoing signaling linkset and 

15 a link within the linkset based on the destination point code and signaling link 
selection code in a message. In SS7 communications, a link is a path to an 
adjacent node. Links are placed into groups, which are referred to as linksets. 
All links in a linkset are capable of accessing the same adjacent signaling 
node. In step ST2, MTP routing process 408 determines whether the 

20 /outgoing signaling linkset is on hold. Determining whether a linkset is on hold 
can be accomplished by reading a flag in a routing table associated with the 
i linkset. The flag may be set by SS7 traffic management processes when a 
link fails. The following is a sequence of events that may occur in a signaling 
gateway or a signal transfer point when a signaling link fails: 



25 
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1 . A link in a linkset becomes unavailable. 

2. The communication module associated with the link notifies 
other modules that its link is unavailable. 

3. The MTP routing functions associated with each communication 
5 module flag the linkset as on hold. MTP layer 3 functions 

associated with the communication module having the failed 
linkset send a changeover message to the adjacent node and 
start a sequence timer to prevent race conditions from occurring. 

4. A message addressed to the on-hold linkset arrives at one of the 
10 communication modules and is enqueued because the linkset is 

on hold. 

5. The linkset goes off-hold because a) the sequence timer 
expires, or b) a changeover acknowledgement message 
received from adjacent node. 

15 6. Messages queued while linkset was on hold are now routed, 

using ticket voucher messages for pacing. 
In step ST3, if MTP routing process determines that the linkset is not 
on hold, MTP routing process 408 simply routes the message to the outgoing 
link. However, in step ST4, if MTP routing process 408 determines that the 

20 linkset is on hold, MTP routing process 408 places the message in ticket 
voucher queue 410. Ticket voucher queue 410 stores the message until a 
ticket voucher request is granted for the message or until the message is 
dequeued by a background process adapted to send MSUs at a low-speed 
rate, such as 600 MSUs/sec, or until it becomes necessary to discard the 

25 message. The operation of ticket voucher queue 410 and the granting and 




requesting of ticket vouchers will b%* discussed in more detail below. Once 
MTP routing process places the message in the ticket voucher queue, control 
returns to step ST1 where the MTP routing process 408 processes the next 
message. 

5 Figure 6 illustrates exemplary steps that may be performed by ticket 

voucher request generator/grant processor 412 in formulating ticket voucher 
requests and processing ticket voucher grants according to an embodiment of 
the present invention. The steps illustrated in Figure 6 assume that the linkset 
to which MSUs in the ticket voucher queue are addressed has gone off-hold. 
10 In step ST1 , ticket voucher request generator/grant processor 412 determines 
m whether MSUs are present in ticket voucher queue 410. In step ST2, if ticket 

bj voucher request generator/grant processor 412 determines that MSUs are not 

M present, ticket voucher request generator/grant processor 412 continues 

= checking. If ticket voucher request generator/grant processor 412 determines 

W 15 that MSUs are present in ticket voucher queue 410, ticket voucher request 
generator/grant processor 412 issues a ticket voucher (TV) request and waits 
for a grant. In order to issue a TV request, ticket voucher request 
generator/grant processor formulates a TV message and sends the TV 
message over the IMT bus. 
20 Figure 7 illustrates an exemplary packet structure for a TV message 

according to an embodiment of the present invention. In the illustrated 
embodiment, TV message 700 includes a destination address field that 
specifies the destination address for the TV message. According to the 
present embodiment, the destination address is an IMT bus hardware address 
25 within signaling gateway 100. Because it is desirable to ensure that all of the 




candidate communications modules on the IMT bus receive the message, the 
destination address 702 is preferably that of the message originator. For 
example, because the IMT bus is of the ring design, the ticket voucher request 
message will pass through each communications module connected to the 
5 IMT bus and eventually return to the originator. 

Ticket voucher request message 700 includes a group/member number 
field 704 for storing a group number or a member number. The group number 
is specified in a TV request to identify the type of cards for receiving the 
request. For example, one group number may indicate that the request is 

10 directed to all LIM cards. The member number is used to distinguish between 
linksets when changeovers occur simultaneously on more than one linkset. 
For example, if two different linksets are on hold simultaneously, ticket 
voucher requests from different cards may be issued simultaneously. Cards 
associated with both linksets may each issue a single grant for the associated 

15 request. Since grants are routed to all cards until they are consumed, one 
card could receive two grants and send MSUs at twice the desired rate and 
another card would receive no grants. Thus, if there is no way for the 
requestor to distinguish between grants, some cards could be "starved" and 
other cards could receive more than their share of grants. 

20 To alleviate these problems, the member number is used to distinguish 

among linksets. If the grant does not contain the expected member number, 
the grant is ignored. Request/grant indication field 706 stores a value that 
indicates whether the ticket voucher flow control message 700 is a request or 
a grant. Grantor present indication field 708 stores a value which is used to 

25 indicate whether a grantor is present for the message. Time-to-live field 710 




stores a time-to-live or hop count value that is decremented by each 
communications module that receives a request to prevent messages from 
looping endlessly within signaling gateway 100. Checksum field 712 stores a 
value for indicating whether ticket voucher flow control message 700 has an 
5 error. 

Returning to Figure 6, in step ST4, ticket voucher request 
generator/grant processor 412 determines whether a grant has been received. 
In step ST5, if a grant has been received, ticket voucher request 
generator/grant processor 412 determines whether the grant contains the 
P 10 expected member number. If the grant does not contain the expected 
fli member number, ticket voucher request generator/grant processor 412 

W ignores the grant and control returns to step ST3 where a new request is 

^ issued. If ticket voucher request generator/grant processor 412 determines 

X~ that the received grant is from the card in the expected linkset, in step ST6, 

O 15 ticket voucher request generator/grant processor sends the MSU at the head 
ti of the ticket voucher queue to an outbound communication module, as 

determined by the SLC and DPC in the MSU. It is not necessary that the 
outbound communication module be the grantor of the request. 

Returning to step ST4, if a message other than a grant is received, 
20 control proceeds to step ST7. In step ST7, ticket voucher request 
generator/grant processor 412 determines whether grantor present field in a 
received message is set to "true" but no grants are available. If the received 
message indicates that a grantor is present but no grants are available, ticket 
voucher request generator/grant processor 412 preferably issues a new 
25 request, with the expectation that grants will later become available. In this 




case, it may be desirable to wait for a predetermined time period before 
issuing a new request in order to allow sufficient time for grants to become 
available. In step ST7, if a ticket voucher message is received and indicates 
that no grantors are available, an error condition occurs and control may 
5 return to step ST1. As seen from Figure 6, ticket voucher requests can be 
used to perform flow control when a link in a linkset fails. 

Figure 8 illustrates exemplary steps that may be performed by ticket 
voucher request processor/grant manager 414 illustrated in Figure 4 in 
processing a ticket voucher request and managing ticket voucher grants. 
C3 10 Referring to Figure 8, in step ST1, ticket voucher request processor/grant 
pi manager 414 receives a ticket voucher request from the IMT bus. In 

! = E 

yj step ST2, ticket voucher request processor/grant manager 414 determines 

2« s whether the ticket voucher request is addressed to its group. This can be 

L. determined by examining the group number in field 704 of ticket voucher 

%i 15 message 700. In step ST3, ticket voucher request processor/grant 
S manager 414 determines whether the request has been granted. This can be 

determined by examining request/grant indication field 706. In step ST4, if the 
request has not been granted, ticket voucher request processor/grant 
manager 414 determines whether its communications module has any grants 
20 available. The determination as to whether any grants are available may be 
performed by monitoring the capacity of the outgoing signaling link associated 
with the interface module that received the grant. 

In step ST4, if a grant is available, control proceeds to step ST5 where 
ticket voucher request processor/grant manager 414 issues a grant to the 
25 requesting card according to a predetermined burst prevention function. For 




example, the card issuing the grant may have an outbound signaling link 
capacity to send 1000 MSUs per second. If 1000 MSUs were enqueued in 
the TV queue, the associated card would issue 1000 back-to-back requests, 
and without any burst management function, the card with available outbound 
5 processing capacity would issue 1000 back-to-back grants. The 1000 grants 
would produce a burst of MSUs to be sent over the outbound signaling link in 
the first part of the available second and no MSUs during the remainder of the 
second. Bursty traffic is more susceptible to loss and hence is undesirable. 
Accordingly, the present invention applies a burst management algorithm 
o 10 when issuing ticket voucher grants. 

fli According to the grant management algorithm, the available time slot 

"yj for sending MSUs is divided into predetermined intervals. For example, if the 

2t time slot is 1 second, the predetermined intervals may be 5 milliseconds. 

L Next, a predetermined number of grants are issued during each time interval. 

P 15 If the available bandwidth is 1000 MSUs/sec. and the intervals are 5 ms, then 
p the number of grants issued during each time interval may be 5. Issuing 5 

grants every 5 ms results in a total of 1000 MSUs/s, which is the available 
bandwidth in this example. Such spacing may be accomplished using a grant 
timer to control the issuance of grants. For example, the timer may be set to 
20 the interval (5 ms). When the timer expires, grants are issued, and the timer 
is reset. No grants are issued until the timer expires. Sending 5 MSUs every 
5 milliseconds for one second uses the same average bandwidth over the one 
second interval as sending 1000 MSUs every 100 ms. However, the latter is 
more bursty. The present invention solves this problem by using a grant timer 
25 to smoothly space grant issuance over an available time slot. 
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In order to issue a grant, request processor/grant manager 414 
changes request/grant indication field 706 to a value that indicates that the 
message is a grant and changes the group/member number field to the 
member number associated with the linkset of the card that issued the grant. 
5 Control then returns to step ST1 to process the next request. 

Returning to step ST4, if the card receiving the ticket voucher request 
determines that no grants are available, control proceeds to step ST6 where 
the grantor present indication in the message is set to true. In step ST7, the 
time-to-live value in the message is checked. If the TTL value is greater than 

10 zero, the TTL value is decremented and the message is forwarded to the next 
card (step ST8). If the TTL value is not greater than zero, the message is 
discarded (step ST9). 

Returning to step ST2, if the request is not addressed to the group of 
the receiving card, ticket voucher request processor/grant manager 414 

15 determines whether the time-to-live value in the message is greater than zero 
(step ST7). If the time-to-live value is greater than zero, ticket voucher 
request processor/grant manager 414 decrements the TTL value in the 
message and forwards the message to the next card time-to-live (step ST8). 
If the time-to-live value is not greater than zero, in step ST9, ticket voucher 

20 request processor/grant manager 414 discards the message. This prevents 
excessive looping on the IMT bus. Once the message has been either 
forwarded or discarded, control returns to step ST1 to process the next ticket 
voucher request. Accordingly, the steps in Figure 8 illustrate exemplary steps 
that may be performed in processing ticket voucher requests. Such steps 




allow receiving cards to efficiently communicate their outgoing link processing 
capability to a requestor. 

The ticket voucher flow control system according to embodiments of 
the present invention performs efficient flow control when a link in a linkset 
5 fails. By controlling the flow of MSUs based on ticket voucher request and 
grant messages, the present invention efficiently regulates the flow of 
enqueued MSUs to outbound signaling links. The present invention also 
includes mechanisms for distinguishing between ticket voucher grants when 
cards associated with two or more linksets simultaneously issue grant 
10 messages. 

Although the embodiments illustrated in Figures 3 and 4 include ticket 
voucher flow control functionality located on link interface modules 300, 302, 
304, and 306, the present invention is not limited to such an embodiment. For 
example, in an alternate embodiment of the invention, a centralized grantor 

15 module may monitor the capacity of all outbound signaling links and issue 
ticket voucher grants in response to the requests, as described above with 
regard to Figure 8. 

It will be understood that various details of the invention may be 
changed without departing from the scope of the invention. Furthermore, the 

20 foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation — the invention being defined by the claims. 



